Asynchronous Data Stream Framework

ABSTRACT

An architecture comprising a hardware layer, a data collection layer and an execution layer lays the foundation for a behavioral layer that can asynchronously access abstracted data. A plurality of data sensors asynchronously collect data which is thereafter abstracted so as to be usable by one or more behavioral modules simultaneously. Each of the behaviors can be asynchronously executed as well as dynamically modified based on the collected abstracted data. Moreover, the behavior modules themselves are structured in a hierarchical manner among one or more layers such that outputs of behavior module associated with a lower layer may be the input to a behavior module of a higher letter. Conflicts between outputs of behavior modules are arbitrated and analyzed so as to conform with an overall mission objective.

RELATED APPLICATION

The present application relates to and claims the benefit of priority to U.S. Provisional Patent Application No. 61/529,206 filed Aug. 30, 2011 which is hereby incorporated by reference in its entirety for all purposes as if fully set forth herein. The present application if further related to the following commonly assigned patent applications: U.S. patent application Ser. No. ______ entitled, “Vehicle Management System”, U.S. patent application Ser. No. ______ entitled, “Modular Robotic Manipulation”, U.S. patent application Ser. No. ______ entitled, “Graphical Rendition of Multi-Modal Data, and U.S. patent application Ser. No. ______ entitled, “Universal Payload Abstraction, all of which filed on Aug. 29, 2012.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Embodiments of the present invention relate, in general, to computer and software architecture and more particularly to systems and methods to facilitate robotic behaviors through an underlying framework of asynchronously updated data streams.

2. Relevant Background

Robots have the potential to solve many problems in society by working in dangerous places or performing jobs that no one wants. One barrier to their widespread deployment is that they are mainly limited to tasks where it is possible to hand-program behaviors for every situation they may encounter. Simply stated, existing robots do not make behavioral decisions. For example, a child as it grows is subjected to numerous learning environments in which the behavioral outcome is supplied. For example, a parent or teacher informs the child how to respond based on their experience or societal norms. Eventually, and as the child matures, it applies these prior experiences to make new behavioral decisions on entirely new environmental situations. Behavior based robotics attempts to provide a robotic system with similar cognitive abilities.

It has been a long established goal and challenge to artificially model human intelligence. One early approach to solving this task is to first build a model of the environment and then explore solutions abstractly before enacting strategies in the real world. This approach places emphasis on symbolic representation and while to a human designer such an approach makes conceptual sense, to a robot which has little or no autonomy, it has little applicability.

One architecture associated with behavior based robotics is known as Subsumption. Subsumption architecture is a reactive robot architecture that decomposes complicated intelligent behavior into many “simple” behavior modules. Each of these behavior modules are in turn organized into layers wherein each layer implements a particular goal and wherein higher layers are increasingly abstract. Each layer's goal subsumes that of the underlying layers, e.g. the decision to move forward by the “eat-food layer” takes into account the decision of the lowest “obstacle-avoidance layer.” Thus subsumption architecture uses a bottom-up design. The general idea is that each behavior should function simultaneously but asynchronously with no dependence on the others. This independence theoretically reduces interference between behaviors and prevents overcomplexity.

In such an approach, each layer accesses all of the sensor data and generates actions for the actuators for the robot with the understanding that separate tasks can suppress inputs or inhibit outputs. By doing so the lowest layers can act as-adapting mechanisms (e.g. reflexes), while the higher layers work to achieve the overall goal.

Another robotic architecture known in the prior art is the Autonomous Robot Architecture (AuRA). This architecture is a hybrid deliberative/reactive robot architecture. Actions that must mediated by some symbolic representation of the environment are often called deliberative. In contrast, reactive strategies do not exhibit a steadfast reliance on internal models, but place a role of representation of the environment itself. Thus, reactive systems are characterized by a direct connection between sensors and effectors. Control is not mediated by this type of model but rather occurs as a low level pairing between stimulus and response.

Structured tasks with predictable outcomes are best suited for a deliberative approach while environmentally dependent task are better suited to the reactive model. Reactive strategies do not exhibit a steadfast reliance on internal models, but displace some of the role of representation onto the environment itself. And instead of responding to entities within a model as is with a deliberative model, the robot can respond directly to perception of the real world. Reactive systems therefore exhibit a direct connection between sensors and effectors and are best applied in complex, real-world domains where uncertainty cannot be effectively modeled.

Some behavior-based strategies use no explicit model of the environment but for more complicated domains it is necessary to find an appropriate balance between reactive and deliberative control.

Increasingly, researchers have abandoned the quest for high-level cognition and instead begun to model lower animal activity. Biology serves not only as inspiration for underlying methodologies, but also for actual robot hardware and sensors. For example a simple household fly navigates using a compound eye comprised of 3,000 facets which operate in parallel to monitor visual motion. In response, an artificial robot eye has been constructed with 100 facets that can provide a 360-degree panoramic view. In another example, artificial bees have been crafted to simulate the dance patterns and sounds of real bees sufficiently well to actually communicate with other bees.

As conceived by one artificial intelligence researcher, “cognition is a chimera contrived by an observer who is necessarily biased by his/her own perspective on the environment. Cognition, as it is a subjective fabrication by an observer, cannot be measured or modeled scientifically.” Accordingly the development of an artificial intelligence capable of cognition remains a challenge. While it remains debatable whether a machine can truly become cognitive, it is generally agreed that a bottom up behavioral approach lays the foundation for all artificial intelligence and a basis for future research. Therefore a challenge remains to develop and implement a bottom up behavioral architecture that can be both deliberate and reactive in response to a multitude of sensory inputs. These and other challenges of the prior art are addressed by one or more embodiments of the present invention.

SUMMARY OF THE INVENTION

An architecture and associated methodology for asynchronous robotic behavior is described hereafter by way of example. An architecture comprising a hardware layer, a data collection layer and an execution layer lays the foundation for a behavioral layer that can asynchronously access abstracted data. A plurality of data sensors asynchronously collect data which is thereafter abstracted so as to be usable by one or more behavioral modules. Each of the behaviors can be asynchronously executed as well as dynamically modified based on the collected abstracted data.

According to one embodiment, behaviors are associated with one of two or more hierarchal behavioral levels. Should a conflict arise between the execution of two or more behaviors, the behavioral outcome is determined by behaviors associated with a higher level arbitrating over those associated with lower levels.

Another feature of the present invention rests in the architecture's ability to support modular behavioral modules. Unlike robotic architectures of the prior art, the present invention provides an architecture in which data collected by a variety of sources is simultaneously available to a plurality of behaviors. For the purpose of the present invention, a behavior is a process by which a specific output is achieved. A behavior may be to identify a target based on a thermal image or it may be to move the robot without hitting an obstacle. Clearly each of these tasks or behavior requires different data, however, the sensors that collect the data may be common. Using the embodiments of the present invention data collected by, for example, a thermal sensor, can be used by both behaviors. The data is collected and processed to a form so that both behaviors can have equal asynchronous access. Moreover the data remains available to other behavior modules that may yet to be connected to the robotic platform. In such a manner the operation of the sensors, processors and behaviors can all operate independently and efficiently.

The behavior engine of the present invention provides a safe reliable platform within onboard intelligence that enables reactive, dynamic and deliberate behaviors. Using an independent asynchronous data collection process, recursive sensor maps can be customized to allow access to data abstractions at multiple levels. Such abstracted data can be used by multiple behavior modules on multiple levels while still providing the ability to dynamically modify the behavioral outcomes based on collected data.

The features and advantages described in this disclosure and in the following detailed description are not all-inclusive. Many additional features and advantages will be apparent to one of ordinary skill in the relevant art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter; reference to the claims is necessary to determine such inventive subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

The aforementioned and other features and objects of the present invention and the manner of attaining them will become more apparent, and the invention itself will be best understood, by reference to the following description of one or more embodiments taken in conjunction with the accompanying drawings, wherein:

FIG. 1 shows an abstract block diagram depicting component layers of an asynchronous data streaming framework according to one embodiment of the present invention;

FIG. 2 presents a high level block diagram for a framework for asynchronous data streaming according to one embodiment of the present invention;

FIG. 3 is a high level block diagram showing general behavior abstraction according to one embodiment of the present invention;

FIG. 4 is more detailed rendition of the behavior abstraction diagram of FIG. 3 with example behaviors and abstractions according to one embodiment of the present invention;

FIG. 5 is a high level block diagram of an example of behavior orchestration using one embodiment of asynchronous data streaming according to the present invention;

FIG. 6 is a flowchart showing one method embodiment of the present invention for asynchronous data streaming according

The Figures depict embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.

DESCRIPTION OF THE INVENTION

An architecture for asynchronous robotic behavior is hereafter disclosed by way of example. The asynchronous architecture of the present invention provides an underlying framework for the application and utilization of asynchronously collected and updated data streams. Asynchronously collected data is abstracted and thereafter provided to a plurality of behavior modules. These modules are combined to form behavior suites which can thereafter be asynchronously executed. These behavior suites operate in what is referred to as a behavior layer that operates on top of a core architecture. The core architecture combines hardware, data collection and execution layers to form a foundation on which a plurality of distinct behaviors can operate.

Embodiments of the present invention are hereafter described in detail with reference to the accompanying Figures. Although the invention has been described and illustrated with a certain degree of particularity, it is understood that the present disclosure has been made only by way of example and that numerous changes in the combination and arrangement of parts can be resorted to by those skilled in the art without departing from the spirit and scope of the invention.

The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of exemplary embodiments of the present invention as defined by the claims and their equivalents. It includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted for clarity and conciseness.

Included in the description are flowcharts depicting examples of the methodology which may be used to asynchronously execute robotic behavior. In the following description, it will be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, can be implemented by computer program instructions. These computer program instructions may be loaded onto a computer or other programmable apparatus to produce a machine such that the instructions that execute on the computer or other programmable apparatus create means for implementing the functions specified in the flowchart block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable apparatus to function in a particular manner such that the instructions stored in the computer-readable memory produce an article of manufacture, including instruction means that implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable apparatus to cause a series of operational steps to be performed in the computer or on the other programmable apparatus to produce a computer implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

Accordingly, blocks of the flowchart illustrations support combinations of means for performing the specified functions and combinations of steps for performing the specified functions. It will also be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, can be implemented by special purpose hardware-based computer systems that perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.

The terms and words used in the following description and claims are not limited to the bibliographical meanings, but, are merely used by the inventor to enable a clear and consistent understanding of the invention. Accordingly, it should be apparent to those skilled in the art that the following description of exemplary embodiments of the present invention are provided for illustration purposes only and not for the purpose of limiting the invention as defined by the appended claims and their equivalents.

Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information. By the term “substantially,” it is meant that the recited characteristic, parameter, or value need not be achieved exactly, but that deviations or variations, including for example, tolerances, measurement error, measurement accuracy limitations and other factors known to those of skill in the art, may occur in amounts that do not preclude the effect the characteristic was intended to provide

As used herein any reference to “one embodiment” or “an embodiment” means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.

As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

In addition, use of the “a” or “an” are employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the invention. This description should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise.

Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for a system and a process for asynchronous robotic behavior through the disclosed principles herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

The behavior-based approach of the present invention is applicable for use in a wide variety of areas, including military applications, mining, space exploration, agriculture, factory automation, service industries, waste management, health care, disaster intervention and the home. To better understand the novelty of the present invention and what behavior-based robotics is, it may be helpful to explain what it is not. The behavior-based approach does not necessarily seek to produce cognition or a human-like thinking process. While these aims are admirable, they can be misleading. While it is natural for humans to model their own intelligence, humans are not aware of the myriad of internal processes that actually produce our intelligence.

A fundamental premise of the behavior-based approach is that sophisticated, high-level behavior can emerge from layered combinations of simple stimulus-response mappings. Instead of careful planning based on modeling, high-level behavior such as flocking or foraging can be built by blending low-level behaviors such as dispersion, aggregation, homing and wandering. Strategies can be built directly from behaviors, whereas plans must be based on an accurate model.

In the architectural style according to one or more embodiments of the present invention, behaviors are arranged into simple, asynchronous layers, each of which corresponds to a task. Higher layers equate to higher-level tasks, and each has the ability to override and interact with children (lower) layers. According to one embodiment of the present invention, behaviors are synchronous and arranged in a tree structure, allowing multiple tasks to occupy the same level or priority. Higher behaviors arbitrate the actions requested by each sub-behavior rather than subsume the lower-level behaviors as has been practiced in the prior art.

The subsumption architecture of the prior art gives each behavior direct, synchronous access to sensors, which the behaviors use to make reactive decisions. The architecture of the present invention also provides access to data collected from the sensors, but it is gathered asynchronously and transformed by a process to abstract the data into a more useful format. Moreover, in the present solution, the data from the sensors can be passed and handled by any of a plurality of behaviors and can be used with different levels of abstraction in different places. Behaviors in the present architecture are not limited to be reactive; they may indeed be dynamic or deliberate. Furthermore, the output of one or more behaviors can be the input to another behavior.

One or more embodiments of the present invention provide a synchronous behavior hierarchy (tree structure) wherein higher-level behaviors arbitrate outputs and requested actions from lower-level behaviors. Behavior modules make decisions from abstracted sensor information that is collected asynchronously and abstracted based on the distinct needs of individual behaviors. The same sensor data can be abstracted differently for other distinct behaviors.

FIG. 1 presents a high level block diagram for a framework for asynchronous data streaming according to one embodiment of the present invention. Five (5) layers comprising a framework 100 for asynchronous data streaming include a hardware layer 110, a data collection layer 130, an execution layer 150, and a behavioral layer 170. As shown, the hardware layer 110 is also associated with a plurality of sensors 115. As one of reasonable skill in the relevant art will appreciate, the depiction shown in FIG. 1 is illustrative only. In other embodiments of the present invention, more or less layers providing additional or less functionality can be included. Indeed the present labeling of the layers shown in FIG. 1 are arbitrary and merely illustrative.

In a subsumption architecture, complicated intelligent behavior is decomposed into many simple behavior modules that are in turn organized into layers. Each layer implements a particular goal of the agent with each higher layer being increasingly abstract. Each layer's goal subsumes that of the underlying layers, thus the name of the architecture. Like the present invention, subsumption architecture is a bottom up design.

In a subsumption architecture, each horizontal layer can synchronously access all of the sensor data and generate reactive actions for the actuators. However, separate tasks can suppress (or overrule) inputs or inhibit outputs. Thus, the lowest layers work like fast-adapting mechanisms while the higher layers work to achieve an overall goal.

The architecture of the present invention invokes the same bottom up structure and each layer can access sensor data but the data is gather asynchronously. Moreover, data in the present invention is made more versatile by an abstraction process. By doing so, the data is placed into a format that can be utilized by a number of different behavior modules simultaneously. Data can also be used with different levels of abstraction in a variety of different locations and, according to one embodiment of the present invention, behaviors associated with the architecture for asynchronous data streaming are not limited to being reactive but are also dynamic and/or deliberate. Behaviors of the present invention are synchronous and arranged in a tree structure, allowing multiple tasks to occupy the same level or priority. Higher behaviors arbitrate the actions requested by each sub-behavior rather than subsume the lower-level behaviors.

Turning back to the architecture for asynchronous data streaming shown in FIG. 1, a behavior layer 170 can be comprised of a plurality of different behavior modules each of which can asynchronously access the data 130 collected by plurality of sensors 115 associated with the plurality of hardware modules 110.

To better understand the organization of the present invention and of the architecture for asynchronous data stream, consider the high-level block diagram shown in FIG. 2. FIG. 2 shows a behavior engine 280 asynchronously receiving inputs from a plurality of behavior modules 270, a plurality of data modules 230, and a plurality of hardware modules 210. According to another embodiment of the present invention, the behavior engine 280 also incorporates input from an operator interface 240. The behavior engine 280 enables various behavior modules to arbitrate actions and tasks requested by any sub-behavior or behavior of an equal level.

Each hardware module 210 is coupled to a physical sensor or other input device and collected data asynchronously from other hardware modules. Thus, a plurality of hardware modules and sensors interact to provide a web of data that can be asynchronously accessed by the behavior modules 270. Moreover, the hardware modules not only are responsible for data collection but also report on whether a specific type of hardware exists and whether the data that is collected is valid. In essence, the hardware modules read data from the corresponding physical hardware sensor or some other type of input device and access its validity. These hardware devices can operate autonomously or be tied to a direct input from a system operator of another component. According to another embodiment of the present invention the hardware modules can operate on a variety of communication mediums such as radio, Internet, USD, and the like. Each hardware module runs in parallel and asynchronously thus allowing data to be collected at a speed that is optimized for the underlying hardware in the overall computing environment.

The data modules 230 gain data from each hardware module 210 as well as from other data modules 230 and prepare a high level abstraction of the data that can be later used by all of the behavior modules 270. Each data module 230 runs independently or asynchronously from each other unrelated data module. According to one embodiment of the present invention, data modules 230 are organized into a directed graph architecture in which individual modules can either push or pull data depending on the environment in which they are operating. Accordingly, each data module represents a specific abstraction of the data. The directed data graph is formed by establishing higher-level data modules as an aggregation of a set of lower-level data modules. The abstraction of data is accomplished by data manipulation to achieve its proper and specified format. Abstraction processing is performed asynchronously with any other type of data or hardware module thus removing any unnecessary alliance between or among unrelated modules.

Behavior modules of the present invention make informed decisions as to what actions take place using the data continuously shared by the data modules. Thus the behavior modules 270 leverage the information gained by the data modules 230. Since the underlying data collection is asynchronous in nature, the speed at which the behavior modules execute is not constrained by the speed of data collection, abstraction, and interpretation. According to one embodiment of the present invention, behaviors are organized into a hierarchy, where additional inputs to each behavior module may be the action or set of actions suggested by lower-level behaviors. However, each behavior module is designed in such a way that it remains encapsulated and does not require higher-level behaviors to operate.

The data modules arbitrate amongst themselves and among sub-behaviors to determine which action should take place. While there is a tree hierarchy among the behaviors, that is there are behaviors and sub-behaviors, the behaviors at the same level possesses equal priority and thus arbitrate among themselves to determine a course of action.

Sensor modules (not shown) which are associated with the hardware module 210 shown in FIG. 2, operate asynchronously to collect and push data to the data modules 230. Once the data is received by the data modules 230, it is abstracted so that it can be equally accessed and utilized by a plurality of behavior modules 270.

The asynchronous architecture of the present invention decouples the collection of data from one or more behaviors seeking a particular type of data. The embodiments of the present invention enable data to be gathered at an optimal rate based on sensor or hardware capability. Each sensor/hardware module operates independently. Accordingly, each behavior can operate at its maximum frequency and capability since it is not slowed by any sensor processing or data delay. And unlike the architectures of the prior art, the asynchronous architecture of the present invention enables behaviors to be incorporated, modified, or removed freely without requiring any changes to the processes and procedures necessary for the gathering of information, as each sensor or hardware module runs independent of the behavior modules. Through the data collected by the hardware modules 210 is independent of the data modules 230 and the behavior modules 270 the data can be stored in a shared data structure making it unnecessary to maintain redundant copies of the data. And as each behavior module, data module, and hardware module operate independently each can run on different processing units or computers based on their individual, computational requirements. As one of ordinary skill in the relevant art will appreciate, the various embodiments of the present invention and the asynchronous architecture for data streaming described above enhances the flexibility and capability of autonomous robotic behavior.

FIG. 3 is a high level hierarchal depiction of the asynchronous data streaming architecture of the present invention. Mission logic 370 is achieved after the arbitration of a plurality of behaviors 340, 350 which asynchronously receive and process abstract data collected by plurality of sensors 310, 315. Each behavior 340, 350 can equally access and utilize various tiers of abstract data 320, 325, 330, 335, which are collected by a plurality of hardware sensors 310, 315. Each tier of abstract data 320, 325, 330, 335 modifies/transforms the data so that may be universally used by one or more behaviors 340, 350.

For illustration purposes, consider the hierarchal structure shown in FIG. 4. FIG. 4 is a depiction of an asynchronous data streaming architecture for achieving a mission logic 470 of “follow target.” As can be seen the architecture includes a plurality of sensors 210, the data collected by each of the sensors 230 and a plurality of behavior modules 270 each of which has its individual capability and task. In this example, two separate range sensors 410, 415 provide data for the various behavior modules. The data collected by the range sensors is abstracted by a plurality of methods so as to provide a variety of tiers of data that can be accessed by the various modules. For example, the 1st tier of data is Filtered Range Data 420 while the second tier of data is an Ego Centric Map 425. In addition, Occupancy Grid 430 and a Change Analysis Map 435 is also provided. Each of these tiers of abstracted data is formed from the raw data collected by the range sensors 410, 415.

The various tiers of data, also referred to herein as data modules or data collection modules 230 are equally accessible by each behavior module. In this example the Guarded Motion Module 440 accesses the Ego Centric Map tier 425 to make its determination or recommendation for action. Likewise the Obstacle Avoidance module 442 seeks data from the Ego Centric Map data tier 425. Similarly, the Follow Path module 444 and the Identify Laser Target module 446 access data from the Occupancy Grid data tier 430 and the Change Analysis Map data tier 435, respectively. The Plug-in Behavior modules do not access abstract data from the rain sensors 410, 415 at all. The Visual Target behavior module 448 and the Thermal Target Identification module 450 operate independently of the data collected from the range sensors 410, 415.

One of reasonable skill in the relevant art will appreciate that each and every behavior modules 440, 442, 444, 446, 448 and 450 can equally access each and every tier of abstract data 420, 425, 430, 435 asynchronously. Moreover, each behavior module is not limited to access to only one data tier. For example, the Follow Path module 444 accesses data from the Occupancy Grid tier 430. While the Follow Path Module 444 only accesses a single abstract data tier it could easily access other data tiers such as the Ego Centric Map 425 or the Filtered Range Data 420. Just as two modules, the Thermal Target Module 450 and the Visual Target Identification module 448, do not access any of the data tiers, any behavior module can access any abstract the data tier as necessary.

The depiction in FIG. 4 shows that each behavior module is provided with data necessary to make its recommendation for an action determination. Each is equally situated to provide input to the mission logic, which in this case is to follow a target. In cases in which the action of one or more modules conflict, the actions are arbitrated to arrive at the desired outcome.

FIG. 4 also shows an overlay of the model architecture shown in FIG. 2 to give the reader a better appreciation for how the various modules interact in arriving at ignition module. In this example, the range sensors 410, 415 are two examples of hardware modules 210. The four tiers of data including Filtered Range data 420, Ego Centric Map data 425, Occupancy Grid data 430, and Change Analysis Map data 435 are modules of collected data 230. Lastly the behaviors including Guarded Motion 440, Obstacle Avoidance 442, Follow Path 444, Identify Laser Target 446, Target Visual Identification 448, and thermal target identification 450 are all behavior modules 270. And while not shown, the behavior module 280 arbitrates the various inputs or action recommendations generated by each behavior module.

Another aspect of the present invention is unique ability to specify and reconfigure behavior orchestration. According to one embodiment of the present invention, the asynchronous architecture described herein enables a mission logic/output to be specified as a unique combination of a plurality of behaviors, sensors, and behavior parameters. As the behavior modules of the present invention are modular and operate independently and mission logic or mission objective can be identified and formed as a combination of these independent modules. The present invention then seeks and incorporates hardware/sensors, abstract data, and various mission behavior outcomes to arrive at the mission logic objective. In this manner, a behavior engine provides a means to optimize the mission behavior dynamically by changing input parameters to the various behavior modules so as to interpret and to respond to various collected data and user input.

Suites of behaviors can also be compiled as separate libraries that can each be customized and distributed to different platforms and/or utilized on different missions while maintaining the same core behavior architecture. Accordingly, the core architecture remains unchanged over various application layers/behaviors that can be continually, and dynamically customized, repackaged and distributed. The asynchronous architecture of the present invention provides cross-application platform technology that is dynamically reconfigurable such that a behavior or outcome can be prioritized based on decision logic embedded in one or more of the behavior modules. A top-level function or behavior module of the overall mission architecture to provide as a means by which prioritize different behavior outcomes and, as described herein, use as the basis to arbitrate between conflicting behavior directives. In essence, each application-centric layer cake uses the same basic behavior modules (modular and reusable modules) but orchestrates these individual behavior modules differently using unique behavior composition and prioritization specifications. By doing so, a user through what is referred to herein as a user control unit or user interface can change behavior goals dynamically and thus reconfigure the mission logic to arrive at the desired optimization and outcome.

FIG. 5 presents a high-level interaction block diagram of an illustrative arbitration process by which a mission logic/outcome is comprised of a plurality of individual/modular behavior inputs. As shown, behavior engine 510 possesses predetermined behavior outcomes or receives a mission logic outcome from a user via a user control unit 575. As illustrated in FIG. 5, the user control unit 575 can be communicatively coupled to the behavior engine 510 via a radio link 570. The behavior engine 510 issues logic directives to a variety and plurality of behavior modules 520, 530, 540, 550, 560. In the example depicted in FIG. 5 a behavior engine 510 communicates directly to a Wander module 540 and a Follow module 530. The behavior engine 510 also communicates to the Follow module 530 and a Way Point Traverse module 520 via a shared Control module 515. The output of the Wander module 540, the Follow module 130, and a Way Point Traverse module 520 is supplied as input to an Avoid module 550 which in turn provides an output to a Guarded Motion module 560. The Follow module 530 and a Way Point Traverse module 520 each receive heading information from the behavior engine 510. This heading information may, in this example, be a general direction which the user wishes the robotic device to traverse.

Using the basic input of heading the Follow module 530 and a Way Point Traverse module 520 provide the Avoid module 550 an initial heading, desired speed and distance. The Wander module 550 provides no heading information but nonetheless provides the Avoid module 550 with a general plan for surveying a general area. These inputs from the various and independent behavior modules are used by the Avoid module 550 to determine an output. Presumably, the Avoid module 550 has certain predefined or user input locations in which the robot is to avoid. Thus the inputs of desire heading, distance, and speed are used and processed by the Avoid module 550 to provide a direction of traverse that both meets mission objectives and the avoidance criteria.

Finally, the output of the Avoid module 550 is provided as input to a Guarded Motion module 560. In this example, the Guarded Motion module 560 may prevent the robotic device from exceeding a particular angle orientation, speed, or any other motion that would jeopardize the platform. The Guarded Motion module thereafter produces an output sent back to the Behavior engine 510 for comparison with the overall mission objective. If the mission objective and the output of the Guarded Motion module 560 are aligned the Behavior engine 510 provides commands to the drive mechanism 580 which correspondingly turns the wheels 590 or acts on a similar device.

The behavior engine 510, in combination with the asynchronous architecture of the present invention, enables modular behaviors to modify collective outcomes so as to meet an overall mission objective. Assume in the example illustrated above that an operator communicated to the particular platform a desired outcome or goal to reposition a robotic device from one point to another. Prior to that input the platform had possessed a general directive to scan and survey a particular geographic region using the Wander module 540. Thus, the new directive provided new direction or goals dynamically that would modify the implementation of the currently operational behavior modules. In this case the wander module 540 was the lowest priority or mission objective and whose output may be modified by the new mission objective.

The new directive to move from one point to another required to Follow module 530 and a Way Point Traverse module 520 to produce a specific heading, speed, and distance. It is possible that the same heading, speed, and distance matched that which had been output by the Wander module 540 or would not conflict with the Wander module output however should there be a conflict the output of the Follow module 530 and a Way Point Traverse module 520 would override that of the Wander module 540. Thus, the Follow module 530 and a Way Point Traverse module 520 would be viewed as being in a higher layer than the Wander module 540.

Another layer higher than all previous modules would be the Avoid module 550. This module ensures that the robotic platform avoids certain predetermined or communicated positions or hazards as identified by onboard sensors. For example, perhaps an onboard sensor identifies a thermal hot spot (fire) that should be avoided or a wireless communication conveys the precise location of an explosive device. The Avoid module 550 would avoid these positions. And lastly, the Guarded Motion module 560 is yet another, and higher, layer than even the Avoid module 550. This module may, for example, guard the platform from certain types of motion that would jeopardize its safety. Each module described herein accesses abstract and asynchronously collected data simultaneously to determine the optimal outcome for that particular module.

Once each module has determined its optimal outcome based on required input data, that being either supplied by another behavior module or data that has been asynchronously collected by one or more sensors, the architecture of the present invention arbitrates the outcomes based on a hierarchal structure determined by the overall mission objective. The behavior engine 510 thereafter compares the recommended course of action based on the arbitrated behaviors of one or more behavior modules to that of the overall mission objective to confirm that the recommended course of action is in compliance with the overall mission objective. Once the directed course of action is confirmed by the behavior, is it is thereafter conveyed to various hardware and logic components to implement commands.

One of reasonable skill in the relevant art will recognize that the example presented above and is depicted in FIG. 5 is only one possible combination of a variety and plurality of modular behavior modules that can be implemented according to a hierarchical architecture using asynchronously collected data.

The process by which an asynchronous data can be used to, in one example, determine robotic behavior in accordance with an overall mission logic is further illustrated by the flowchart of FIG. 6. According to one embodiment of the present invention, a process by which to asynchronously provide data to a plurality of behavior modules begins with the collection of data 610. As has been previously described, data is collected asynchronously by a plurality of hardware modules or sensors. As the data is collected it is abstracted 620 and provided for asynchronous access by a plurality of behavior modules 640. According to one embodiment of the present invention, one or more behavior modules can be combined 670 to form what is referred to as a behavior suite. Behavior suites can then be treated either independently or in conjunction with other behaviors in the determination of a recommended action. And finally, the behavior suites are executed 680 to achieve the desired mission outcome.

The architecture of the present invention facilitates the development and implementation of modular robotic behaviors. By providing an underlying framework of asynchronously updated data streams that can be universally accessed by one more behavior modules, the capabilities of a wide variety of robotic platforms can be modified and tailored to meet specific mission needs. Moreover, the same platform can be quickly modified using plug-and-play modules to provide new capabilities without having to modify the collection and preparation of sensor data. Modules can be interchanged between platforms with confidence that each platform will provide to the newly incorporated module the information it needs to accomplish its mission.

The core architecture of the present invention comprised of the hardware layer, the data collection layer and the execution layer enables behaviors associated with the behavior layer to operate independently and to be modified dynamically. Asynchronously collected data is abstracted so as to be useable by a plurality of data modules simultaneously. Moreover, the use of a set of abstracted data by one behavior module is completely independent of the simultaneous and continuous use of the same data, albeit abstracted differently, by a different behavior module.

The architecture of the present invention also enables behavior modules to be dynamically modified responsive to collected data. Should data indicate that the current parameters of a particular behavior are not compatible with the overall mission objective based on the collected data, the parameters can be modified without modifying the data collection means or processing. Once the module has been modified it can again access the collected data to initiate a responsive action.

In situations in which two or more actions developed by behaviors of the same hierarchal level conflict, a resolution is reached as to which behavior should be applied based on desired higher level behavioral outcomes. The architecture and associated methods of the present invention provide a significant advance over the prior art and address many of the challenges in robotic behavioral control.

As will be appreciated by one skilled in the relevant art, one preferred means of implementing the present invention is in a computer system as software, hardware or a combination thereof. These implementation methodologies are known within the art and the specifics of their application within the context of the present invention will be readily apparent to one of ordinary skill in the relevant art in light of this specification and as described below.

For example, one more embodiments of the present invention may be implemented in a computer system as a program of instructions executable by a machine. In such an implementation, the program of instructions may take the from as one or more program codes for collection data asynchronously, abstracting the data, accessing the abstracted data asynchronously by one or behavior modules and then code for executing the modules.

Some other possibilities for implementing aspects of the systems and methods include micro-controllers with memory (such as electronically erasable programmable read-only memory (EEPROM)), embedded microprocessors, firmware, software, etc. Computer-readable media in which instructions may be embodied include, but are not limited to, non-volatile storage media in various forms (e.g., optical, magnetic or semiconductor storage media) and carrier waves that may be used to transfer such formatted data and/or instructions through wireless, optical, or wired signaling media or any combination thereof.

As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the modules, managers, functions, systems, engines, layers, features, attributes, methodologies, and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions, and/or formats. Furthermore, as will be apparent to one of ordinary skill in the relevant art, the modules, managers, functions, systems, engines, layers, features, attributes, methodologies, and other aspects of the invention can be implemented as software, hardware, firmware, or any combination of the three. Of course, wherever a component of the present invention is implemented as software, the component can be implemented as a script, as a standalone program, as part of a larger program, as a plurality of separate scripts and/or programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of skill in the art of computer programming. Additionally, the present invention is in no way limited to implementation in any specific programming language, or for any specific operating system or environment. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims. 

1. An architecture for asynchronous robotic behavior, comprising: a hardware layer including a plurality of sensors operable to collect sensor data; a data collection layer wherein the data collection layer is operable to abstract collected data; a synchronous behavior layer having a plurality of distinct behaviors wherein each behavior is associated with at least one of at least two hierarchal behavioral levels and wherein higher behavioral levels arbitrate lower level behavior output; and an execution layer operable to asynchronously execute distinct behaviors responsive to behavior level arbitration.
 2. The architecture for asynchronous robotic behavior of claim 1, wherein sensor data is collected asynchronously.
 3. The architecture for asynchronous robotic behavior of claim 1, wherein sensor data is processed independent of the plurality of distinct behaviors.
 4. The architecture for asynchronous robotic behavior of claim 1, wherein sensor data is uniquely abstracted for use by each of the plurality of distinct behaviors.
 5. The architecture for asynchronous robotic behavior of claim 1, wherein sensor data from two or more sensors is aggregated into a data module.
 6. The architecture for asynchronous robotic behavior of claim 5, wherein each data module abstracts the aggregate sensor data independent of any other data module.
 7. The architecture for asynchronous robotic behavior of claim 5, wherein sensor data from two or more data modules is aggregated into a higher level data module and wherein each higher level data module abstracts sensor data independent of any other data module.
 8. The architecture for asynchronous robotic behavior of claim 1, wherein sensor data is continuously shared by the plurality of distinct behaviors.
 9. The architecture for asynchronous robotic behavior of claim 1, wherein sensor data is uniquely abstracted for each of the plurality of distinct behaviors.
 10. The architecture for asynchronous robotic behavior of claim 1, wherein a subset of the plurality of distinct behaviors can be of the same hierarchal behavioral level.
 11. The architecture for asynchronous robotic behavior of claim 1, wherein each distinct behavior of the plurality of distinct behaviors is independent of each other distinct behavior.
 12. The architecture for asynchronous robotic behavior of claim 1, wherein each of the plurality of distinct behaviors includes one or more parameters.
 13. The architecture for asynchronous robotic behavior of claim 12, wherein one or more parameters of the plurality of distinct behaviors can be dynamically modified.
 14. The architecture for asynchronous robotic behavior of claim 13, wherein the one or more parameters are modified responsive to one or more of asynchronously collected sensor data, user inputs, or automated learning mechanisms.
 15. The architecture for asynchronous robotic behavior of claim 1, wherein each of the plurality of distinct behaviors can independently and simultaneously access and use collected sensor data.
 16. The architecture for asynchronous robotic behavior of claim 1, wherein collection and processing of sensor data is independent of behavior execution.
 17. The architecture for asynchronous robotic behavior of claim 1, further comprising a first behavior associated with a first behavior level and a second behavior associated with a second behavior level, the first level being higher than the second level, wherein output from the second behavior is responsive to conditions set by the first behavior
 18. The architecture for asynchronous robotic behavior of claim 17, wherein the first behavior is dynamically reconfigurable.
 19. A method for asynchronously executing robotic behaviors, the method comprising: collecting data asynchronously from a plurality of sensors; abstracting the collected data wherein the abstracted collected data is simultaneously available to each of a plurality of behavior modules, and wherein each behavior module is associated with at least one of at least two hierarchal behavioral levels; responsive to two or more behavior modules associated with the same hierarchal behavioral level conflicting, arbitrating conflicting behavior modules based on desired higher level behavioral outcomes; and asynchronously executing the plurality of behavior modules. wherein abstracting collected data is independent of the plurality of behavior modules.
 20. The method for asynchronously executing robotic behaviors according to claim 19, wherein collecting data and abstracting of collected data is independent of behavior module execution.
 21. The method for asynchronously executing robotic behaviors according to claim 19, wherein abstracting collected data includes uniquely and asynchronously preparing data for each of the plurality of behavior modules.
 22. The method for asynchronously executing robotic behaviors according to claim 19, further comprising aggregating data from two or more sensors forming a data module.
 23. The method for asynchronously executing robotic behaviors according to claim 22, further comprising abstracting the collected data associated with each data module independent of collected data associated with each other data module.
 24. The method for asynchronously executing robotic behaviors according to claim 19, further comprising simultaneously sharing abstracted collected data to the plurality of behavior modules.
 25. The method for asynchronously executing robotic behaviors according to claim 19, further comprising dynamically modifying behavior module parameters.
 26. The method for asynchronously executing robotic behaviors according to claim 25, wherein modifying occurs responsive to one or more of asynchronously collected sensor data, user inputs, or automated learning mechanisms.
 27. The method for asynchronously executing robotic behaviors according to claim 19, wherein a first behavior module is associated with a first behavior level and a second behavior module is associated with a second behavior level, the first level being higher than the second level, and further comprising setting output parameters for the second behavior by the first behavior module.
 28. A computer-readable storage medium tangibly embodying a program of instructions executable by a machine wherein said program of instruction comprises a plurality of program codes for asynchronously executing robotic behaviors, said program of instruction comprising: program code for collecting data asynchronously from a plurality of sensors; program code for abstracting the collected data wherein the abstracted collected data is simultaneously available to each of a plurality of behavior modules, and wherein each behavior module is associated with at least one of at least two hierarchal behavioral levels; program code responsive to two or more behavior modules associated with the same hierarchal behavioral level conflicting, arbitrating conflicting behavior modules based on desired higher level behavioral outcomes; and program code for asynchronously executing the plurality of behavior modules.
 29. The computer-readable storage medium tangibly embodying a program of instructions of claim 28, further comprising program code for dynamically modifying behavior module parameters responsive to asynchronously collected data
 30. The computer-readable storage medium tangibly embodying a program of instructions of claim 28, wherein collecting data and abstracting of collected data is independent of behavior module execution
 31. The computer-readable storage medium tangibly embodying a program of instructions of claim 28, further comprising program code for aggregating data from two or more sensors forming a data module
 32. The computer-readable storage medium tangibly embodying a program of instructions of claim 31, further comprising program code for abstracting the collected data associated with each data module independent of collected data associated with each other data module
 33. The computer-readable storage medium tangibly embodying a program of instructions of claim 28, further comprising program code for simultaneously sharing abstracted collected data to the plurality of behavior modules.
 34. The computer-readable storage medium tangibly embodying a program of instructions of claim 28, further comprising program code for dynamically modifying behavior module parameters.
 35. The computer-readable storage medium tangibly embodying a program of instructions of claim 34, wherein the program code for modifying occurs responsive to one or more of asynchronously collected sensor data, user inputs, or automated learning mechanisms. 